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Summary 

TICS (Teacher-Interactive Computer System) is 
an on-llne.and interactive prograrmning system for 
authoringy4hteractive programs, pajfticularly in^ 
structional programs of various types. The system 
provides a fairly natural language, in which the 
author's statements for creating items in a pro- 
gram, for examining the structure and flow, for 
simulating its use by students, for modifying the 
exi sting ides^ri pti on , and for maki ng en t ri es i n a 
"thesaurus/ehcycldpeaia'' can be intennixed homoge- 
neously. During the authoring process, the current 
specification of a program is stored dynamically 
as a structured data base, which includes automat- 
ically-generated infonnaticn relating to the inter- 
dependencies an:ong items in the program and other 
diagnostically useful data. Impten'^nted in a large, 
general purpose tiire-snaring system (Multics), the 
TICS authoring systs- is cc~?]cn:entcd by a delivery 
system for student use of the programs. It is also 
Intended to provide automatic conversion of com- 
pleted programs to alternate formats for implemen- 
tation on other computers. 

Introduction 



In this paper, we describe an interactive 
programming system: TICS (for Teacher-Xpteractive 
Computer ^ System) in terms of its application to 
the authoring and use of computerized instructional 
programs. Which we call Tutorials. This system, 
more than other prograir^ning languages and systems 
which have been applied to similar purposes, ^""^ 
treats the authoring of a Tutorial as a dynamic 
process which itself requires significant computer- 
ized assistance. 

We regard Tutorial programs as defining an 
Interaction which is primarily controlled by the 
computer (that is, by the author) but with the stu- 
dent being able to direct the flew either implicit- 
ly by his responses, or explicitly by direct re- 
quests. During that interaction an attempt may be 
made to stimulate the student by offering informa- 
tion, asking questions, anj soliciting responses; 
the computer should also be able to respond to the 
student's questions, even if within a limited 
framework. A particular student will see a 
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sequence of such actions; with the detail of the 
content. varying in a manner which depends on his 
ininediately^preceding response, previous responses, 
and other parameters. 

In writing a Tutorial, the author is con- 
cerned with a multi-dimensidhal object, for which 
he heeds to consider both the>overall design and 
specific details at different points--6fteri at 
essentially the same moment; The notion that he 
might, write the program by presenting a one-dimen- 
sional sequential list of "instructions" starting 
at one end of the object and going to the other, 
is not accurate, even though that view is' so fund- 
amental an aspect of most prdgrarrming languages 
that non-professionals often identify it as the 
process, of programming a computer. TICS, on the 
other hand, assumes that the author will move 
around within the ongoing description cf his 
tutorial. It also recognizes that the acts of 
describing items in the Tutdrial, of examining the 
Tutorial, of trying it to see how it works, of 
changing it or adding to it on the basis of look- 
ing at it (in the general sense), and even of in- 
serting data into ah information data base for the 
student are all intim.ately related aspects of the 
one dynamic process of writing a Tutorial. There- 
fore, the TICS coiTjnands which relate to all of 
those, different kinds of activity are available 
to the author at any time, regardless of the then 
current state of his program, and the various 
types of actions may be mixed in a natural way, 
according to his own predilection. Many of the 
available instructions are analogous to program- 
ming language statements, in that they specify ac- 
tions which are to occur and the Idgical decisions 
which should be made when the student uses the 
program. However, unlike a programming language, 
in which statements are considered to be simply a 
sequence of program steps, the TICS system trans- 
forms the authdr*s ongoing input into a data base 
of fairly general structure, which is called the 
"dynamic data base". The predefined structural . 
form of the data base is a direct reflection of 
the system's conceptual model for a Tutorial, 
which is described in some detail in a later sec- 
tion. 

In addition to providing a reasonably natural 
language to the author for the creation of a Tutor- 
ial and for reviewing its content, logic and struc- 
ture, the system assumes the burden of managerial 
tasks, such as numbering items, recording inter- 
dependencies among items, and keeping track of 
structural incompleteness. The system also in- 
cludes mechanisms to convert the author's 



description of a Tutorial Into a concise form for 
student use on one or more "target" machines, not 
necessarily the same type of computer on which 
the TICS author-system Itself resides. 

The Overall System 

TICS Is Implemented at M.KT. as a subsystem 
in the Multlcs^ tln^e-sharlng system. Figure 1 
diagrams some aspects of Its organization and in- 
put-output modes. Within the author system, each 
Tutorial-in-process is errbodied in one "dynamic- 
data-base", resident in Multics storage. The au- 
thor can work on his description of a tutorial 
through an on-line teminal or via off-line media 
(e.g., cards, printer). He can al lev; .a "try out" 
access to others who then can use, but not alter, 
the program, while it is still being developed and 
even if It contains structural errors I Any number 
of authors may-work simultaneously, each on. his or 
her :dwn . tutorial; An authdf^iray work, on as many^ 
different tutdif^ials as he chooses and, conversely. 
It can be arranged" that any number of. authors can 
work on one tutorial. 

When a Jutorial is thought to be finished, 
the author Initiates "a transformation process 
(analogous to compilation), which we call compres- 
sion^ That process comprises the various steps 
of ordering^the data base, searching, for structur- 
al errors, extracting only those elenients which are 
needed for the-execution-tiire description of the 
Tutorial, and fomatti rig them into a highly coded, 
compressed form. This is used in the delivery 
system, also Implemented on Multics, in conjunction 
with a driver program. (Driver programs are. also 
being written in ISM/PLl and for a PDF 11/40 
system.) 

The; Structure of a TICS Tutorial 

We regard the structure of a Tutorial as be- 
ing representable by a collection of nodes , inter- 
connected by arbitrary numbers of brancnes. Each 
node can contain a slnall interaction, ideally a 
tiny conceptual unit in the author's plan. One 
node In a program has the initial attribute and 
acts as the starting point. Any number of nodes 
may be points at which the Tutorial ends. Gener- 
ally, branches are specified explicitly, although 
conditionally (e.g;: if "such and such" is true, 
then go to node "such and such"). In addition, for 
certain types of nodes, or clusters of nodes, a 
branch out need not be explicitly identified but 
can be a return to the point where the branch into 
the cluster originated. 

Assuming that the allowable contents of a node 
are adequate, these simple structural concepts al- 
low a Tutorial to be very general from a purely 
Structural point of view. Moreover, there are 
three aistinct and important advantages in the node/ 
branch concepts and the associated multi-level 
address space defined within each Tutorial: 
1) It provides a convenient structural form for 
the dynamic data base, which in turn allows the pro- 
vision of author commands which are both convenient 
and efficient in maintaining, manipulating, and In- 
vestigating that data base. 2) For the author, 



the nodes might comprise intellectually meanTng- 
ful units. Also, since they are readily distin- 
guishable and clearly delineated locations in the 
overall structure, the nodes constitute a refer- 
ence basis by which tne author (or a later modi- 
fier of the program) can move around within the 
already existitig description. 3) Implementation 
of the target (delivery) system for student use 
is conceptually s'impler with the nodal concept, 
and the inherent/ demarcation lines in the final 
progratn description provide an opportunity for 
efficient utilifation of limited core storage in 
a special purpose, multi-user, time-sharing stu- 
dent system. 

It is of equal importance to note thct the 
nodal structure is not selected because of any 
presumed advantage it holds as a -fonnat for pre- 
sentation to the student. Indeed, -although an 
obviously "page-by-page" presentation can be writ- 
ten, such great' variations in ^the contehts\of 
nodes are^pdssible that students will hdt general- 
ly discern the node boundaries even if they are 
aware of the underlying nodal structure of. the 
programs ♦ 

For Tutorial programs, we may envision nodes 
as having a specific internal structural pattern 
(which need not^be filled) as indicated schemati- 
cally in Figure 2. within any dne node there may 
be 1) execution of called subroutines, 2) out- 
puts to the student, 3) acceptance of a response 
from the student (if one ms anticipated), 4) 
analysis (mapping) of the response with respect to 
a list of anticipated responses, and 5) testing 
of "condition statements" which, if true, cause 

, associated sequences of actions tobe carried out. 

"The conditions to be tested can relate to the stu- 
dent's response in the current node, to responses 
in other-nodes, and to values of variables. The 
action sequences can incluae calling subroutines, 
printing statements," writing entries in a report 
file, doing mathematical operations on arithmetic 
variables, executing "return" type nodes or node 
clusters, printing hints (and getting other re- 
sponses), and (sooner or later) branching to 
another node. 

In addition to the description for those con- 
tents, which specify what the program should do 
when the student is using it, each node may have 
a number of additional items associated with it, 
while the author is working on the program. These 
Include a name, a number, a documentation comment, 
a self-reminder author message, a system-maintained 
set of warning and error messages relating to 
changes made in interdependent items, a system- 
maintained list of all items in the node on whjch 
other items depend, optional attribute specif.lca- 
tions which relate to the. interpretation of the 
student*s response, and one or more keyword phras- 
es. Using a subset of the node-keyv/ord pairs ^ — 
(which is then included in the student's version of 
the program), the teacher can identify those points 
in a Tutorial to which a student may arbitrarily 
skip, and at the same time provide the "map" for 
the student to appreciate what those points are 
about. 
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There are, additionally, implicit items in 
the description of every node because of certafn 
operational conventions which are followed when 
the Tutorial is being used: 1) If a response 
does hot result in a hint or a branch-out, the 
system defaults to a n;ulLiple-choice mooe, in ef- 
fect asking the student to select airiong the 
responses anticipated by the author. 2) If a 
hint is given, the associated staternent Is checked 
off, so that the sarr.e.hint is not given again in- 
auvertently. It may be noted that zhese conven-. 
tlons eliminate the possibility of looping" of- 
of a dead end occurring v/ithin a node, providing 
that at least one anticipated response (or ah al- 
ways true conditional) necessarily leads to a 
branch-out. ' This ccnaition is readi.ly checked 
and Is monitored by the system. Another implicit 
item in therTutorial is the optional recording of 
the^history of the student's path, including the 
full text of his responses, these data may be use- 
ful to the author or to the instructor of the re-^ 
lated course, if the uie of the Tutorial is formal- 
ized. 

There are also three types of global items 
associated with each Tutorial which apoly through- 
out, Tather than to a specific node: IJ A data 
base for author-specified nun;erical scalar, numer- 
icaT array, and character, variables, and for a 
number of systen^-naintained variables, which r;ay 
be p re-initialized or derived, from student input, 
included in text output, manipulated by erith-etic 
(and character) operations and subroutines, and 
used in making decisions. 2) An organized file 
of textual infom.ation, called a thesaurus/encyclo- 
pedia. 'Words and phrases can be linkec to one a- 
nother in the sense of a thesaurus and associated 
with-descriptive text in the sense of a dictionary 
or encyclopedia. In use, the student can access 
the information from any point in the tutorial 
through the use of "interruoti ve" requests. 
3) There are seven types of interrupti ve reauests 
with which the student can change or" temoorarily * 
interrupt the flov/. Three of tnese require no 
action by the author; the student can back up 
to a point v/here he gave a response previously; 
send a message to whcr.ever is in charge of the 
use of the tutorial; or stop the session, with the 
option of continuing at a later tinie. Three more 
requests are always irr.plicitly available, but are 
useful only if the teacner supplies appropriate 
data. These allow the student to search through 
and look up items in the thesaurus/encyclopedias; 
search the key\7ord phrase list; and jump to points 
identified in the keyv/ord list. In addition to 
these, the teacher may specify subroutines to be 
made available and their names may then be used 
as interruptive requests, with or without student- 
supplied parameters. 

Authoring a Tutorial 

The author is always considered to be at a 
certain node in the Tutorial, the working nooe . 
The working node may be relocatea to any noae by the 
use of a simple cormano, and the consequent ease of' 
moving the site of operation among the nodes helps 
to make the oescription of a non-linear Tutorial a 



natural process. With other commands, the author 
can create specific items within the Tutorial, 
generally at his working node. The elements of a 
node may be created in the order in which they will 
be executed or in any other order that the author 
finds natural. Since a"ny one statement may call; 
either explicitly or implicitly, 'for the creation 
of a number of new items in the program, the systen 
infonns the author of the specific entries made in 
the dynamic data base and of the unique identifier 
assigned to each item, which may be, used thereaft- 
er to refer to the item without repeatinc its com- 
plete specifications. The system gives v/arnings 
and my seek verification of possibly- unexpected 
creations (e^,_the implied creation .of i new var- 
iable or of an anticipated respdnse in another node) 
and input statements are checked for consistency 
with:,the existing data base^as well as for lan- 
guage syntax.. When ah error .occurs, a descriptive 
message is printed, and. the..author may. switch to 
a general purpose editor to fix the statement. 

The same editor is called at the author's 
request to alter any, previously specified textual 
entry in the program. Other modifications to exist- 
ing entries may involve deletions, rearranging the 
oroer of things, changes in the logical structure, 
or substitution of one item for another and appro- 
priate commands are therefore provided. 

"Shorthand" features are provided to give the 
lanauage added convenience. An- author may define 
an input shorthand for commands or for text which 
he uses often, and previously specified text may 
be used, by reference, as input in creating new 
entries. The author cSn also control the verbosity 
of the computer feedback and, if he chooses, switch 
to a block input mode to vary his. pattern of inter- 
action with the computer. Moreover, all facilities 
in the system except those which obviously require 
the author's live presence (such as sim.ulation)> 
can be used in an off-line, card-input mode. 

To help the author keep track of the inter- 
relationships among items in the tutorial, a cross 
reference table is maintained for each node. These 
tables are available to the author and are also 
monitored automatically to determine what effect 
modifications have on items elsewhere in the Tutor- 
ial; when an item is altered, an appropriate warn- 
ing entry is mane in any affected node(s). If an 
item is deleted from the program, such that some 
other item is Dut in error, a non-deletable error 
entry is made in any node(s) containing the erro- 
neous item(s), and the deleted entry is actually 
saved in "ghost-like" form, so that it may te rein- 
stated, if desired. Such error entries can be re- 
moved only by correcting the erroneous conditions. 

The ease with which the original author and 
subsequent contributors can refine a Tutorial de- 
pends greatly on their being able to inspect and 
review its contents; The TICS system therefore pro- 
vides a variety of tools for viewing the structure 
and the content of a Tutorial, in coarse or fine 
grain, on the author's console or via a remote high- 
speed printer, in print or graphical form. Another 
set of coninands is provided for focusing on the 



logical' structure of the Tutorial; that is, for 
looking at possible paths through the node/branch 
structure. One such command is the tree command 
which allows the author to view the branching 
structure starting or ending at, a given node. A 
trace command "plays through" the outputs, student 
responses, and conditional choices involved in a 
path through a set of nodes. Another command 
yields a:block diagram of the internal logic of a 
single node. 

An important part of the authoring process is 
for the; author to "see how it runs"; that is, to 
execute the Tutorial as a student. For this pur- 
pose, the system includes a mode of operation in- 
tended; to, simulate the execution of a program as 
It will appear to the student, but which works oh 
\ the author's dynamic data l?ase,. which may be s true- 
st u rally incomplete and erroneous; (Such cohdi- 
t;i^ns-are detected' during simulation and brought 
to\the author's attention.) There are, moreover, 
two rfiiodes -of simulation: a) Student- (or "derrid") 
modCi for which the target system interaction is 
emulated as precisely as possible and which can pro- 
vide actual user feed-back during the entire pro- 
cess of writing the tutorial, b) Teacher (or 
"ron-denio") mode, in which the system not only pre- 
sents the described interaction, but also identifies 
each node as it is entered through the branching 
sequences, prints the error, warning and reminder 
messages which nappen to be attached, and makes 
additional comments about incomplete states. In 
addition, during the course of the simulation, the 
author then has available a number of con^iiands for 
the purpose of examining and setting values for 
variables, and for controlling the simulation. He 
can set detailed "stop-points" within nodes, which 
will cause a halt in the simulation and allow exam- 
ination of the state of affairs at the instant. 
Throughout, the author may use any of the standard 
TICS requests to create, display, examine or alter 
any part of the Tutorial description. 

Anticipated Responses and Response Analysis 

For the interaction format described earlier 
which has the flavor of a "conversation" between 
the computer and the student, and especially if 
the student responses are the prime determinant of 
the program flow, specification of anticipated stu- 
dent responses are a central aspect of the author- 
ing process. If, in addition, free fonriat student 
responses are desired, rather than (say) multiple- 
choice selection, response analysis (or interpreta- 
tion) with respect to the anticipated responses is 
a critical function of the delivery system. 

The generalized fesponse analysis problem js 
made more- tractable by the structure of the Tutor- 
ial which allows each individual analysis to be 
made In a very local context, and reduces the prob- 
lem from "what does it mean?" to "does it mean the 
same as one of the anticipated responses". It is 
worth noting, as a related point, that there is not 
much advantage gained by a response analyzer which 
"understands" responses for which the rest of the 
Tutorial is not prepared. In a real sense, there- 
fore; an author's success is more dependent on the 



degree to which he becomes not only aware of but 
also responsive to the meani nqful range of student 
responses in each node, curing the dynamic process 
of design and trial of a Tutorial-. _ ^ 

While trying not to involve the system or the 
author deeply in questions of language^ structure 
or analysis, requiring certain simple specifica- 
tions to indicate alternatives for the response 
comparison process has been useful in allowing 
reasonably natural student responses. Thus, a node 
may give the student a multiple-choice presentation 
directly or look for a^free-format response; or, it 
may seek a response which is actually a lint of 
responses. It may seek no response, or re-inter- 
pret a, previous one with respect to-a^different set 
of anticipated. responses. Each anticipated response 
carries its own instructions for the response com- 
parison routines; these may indicate, for example, 
that the expected response is a number between spec- 
ified limits, or ah algebraic expression or equation, 
both of which require a mapping very different than 
for text. Text responses may be finely detailed in 
terms of pieces which should or should not be in- 
cluded, in terms of listing synonomous or alterna- 
tive forms, in terms of the exactness of match re- 
quired, and in other respects. Additional alterna- 
tives regarding response analysis are implicit in 
the author's option of using subroutines to act 
directly on the input text. 
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